REMARKS 



Claims 2, 5-7, 10, 11, 20, 22, 29, and 30-32 are pending in the application. 

Claims 2, 6, 11, 20, 22, 29, and 30 are currently amended; claims 18 and 19 are canceled; 
and new claims 3 1 and 32 are added. 

Claim 22 stands rejected under 35 U.S.C. §112, second paragraph. 

Claims 2, 5-7, 10-11, 18-20, and 29-30 stand rejected under 35 U.S.C. § 103(a) as 
unpatentable over U.S. Patent Application Publication No. 2002/0120763 to Miloushev et al., 
hereinafter, Miloushev, in view of IETF RFC 1094 "Network File System Protocol 
Specification", hereinafter, RFC 1094. 

Claim 22 stands rejected under 35 U.S.C. § 103(a) as obvious over Miloushev, in view of 
RFC 1094, and further in view of IETF RFC 791, hereinafter RFC 791. 

Applicant respectfully traverses the rejections based on the following discussion. The 
following paragraphs are numbered for ease of future reference. 

I. The 35 U.S.C. §112, Second Paragraph, Rejection 

[0001] Claim 22 stand rejected under 35 U.S.C. §1 12, second paragraph, because the 
Examiner is unclear as to whether a single Ethernet packet or a plurality of Ethernet packets is 
sent to the client computer. 

[0002] Applicants have currently amended claim 22 to recite in relevant part, "said 
virtualizer dividing said single response into a plurality of standard Ethernet packets to send to 
said client computer as multiple standard Ethernet packets." Applicants respectfully submit that 
in dependent claim 22, a single response comprising multiple standard Ethernet packets is sent to 
the client computer. 

[0003] For at least the reasons outlined above, Applicants respectfully submit that 
currently amended claim 22 particularly points out and distinctly claims the subject matter which 
Applicants regard as the invention. Therefore, Applicants respectfully submit that currently 
amended claim 22 fulfills the statutory requirements of 35 U.S.C. § 1 12, second paragraph. 
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Withdrawal of the rejection of claim 22 under U.S.C. §112, second paragraph, is respectfully 
solicited. 

II. The Prior Art Rejections 

A. The 35 U.S.C. 103(a) Rejection over Miloushev and RFC 1094 
1. The Miloushev Disclosure 

[0004] It is a fact that Miloushev discloses, " An apparatus and method are provided in a 
computer network to decouple the client from the server, by placing a transparent network node, 
also termed a file switch or file switch computer, between the client and the server. Usage of 
such a file switch allows reduced latency in file transfers, as well as scalable mirroring, striping, 
spillover, and other features." (Abstract). 

[0005] It is a fact that Miloushev discloses, "Another aspect of the present invention is a 
network node that aggregates the namespaces of multiple independent file servers and presents 
them as a single, unambiguous namespace to network clients by switching file protocol 
transactions initiated by said clients among said servers using only file system paths contained in 
said transactions and information available within said network node at the time the switching 
decision is being made." (paragraph [0061]). 

[0006] It is a fact that Miloushev discloses, "In addition, the following advantageous 
combinations of features and layouts of the inventive system are provided herein: an architecture 
including multiple file switches all identified under a single server name within a network; a 
method and system providing load balancing through a combination of a name resolution 
mechanism and a group controller mechanism; a method and system providing network function 
failover through a combination of a name resolution mechanism and a group controller 
mechanism; a network file system comprising a file switch and a plurality of file servers; a 
system, comprising a plurality of file switches and a plurality of file servers, in which the file 
switches synchronize access to the file servers using only synchronization mechanisms and 
protocol provided by the file servers; a switched file system in which a switch provides a caching 
function for either clients or servers; a switched file system in a network in which only 
commercially available software is required for member clients and servers to function; a 
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switched file system administered as a single file server; a switched file system in which capacity 
and bandwidth can be scaled independently; a method and system providing opportunistic 
locking functionality and keeping a file open while maintaining a local copy of the file as cache 
in a gateway topology." (paragraph [0087]). 

[0007] It is a fact that Miloushev discloses, "Since most popular network file protocols 
are based on the IP standard, the file switch preferably supports TCP and UDP IP network 
protocols, as well as other protocols of the IP stack (e.g., ARP), as appropriate. The file switch 
preferably supports multiple industry standard network file protocols, such as NFS and CIFS." 
(paragraph [0123]). 

[0008] It is a fact that Miloushev discloses, "FIG. 1 illustrates an inventive network 
configuration including a file switch. In this configuration, the file switch 100 is implemented 
with two different network interfaces: one for connecting to the client network 111 through 
connection 109, and the other for connecting to a file server network through connections 110, 
114 and other similar connections as shown. For simplicity, the file switch is illustrated 
connected directly to each of the file servers 101 through 107; in practice, one or more 
commonly available layer 2 switches are preferably used to implement these connections." 
(paragraph [0124]). 

[0009] It is a fact that FIG. 1 of Miloushev discloses, 
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FIG. ? 

[0010] It is a fact that Miloushev discloses, "Network file protocols are typically based 
on transactions. FIG. 2 illustrates a typical file write transaction in a network file protocol. The 
transaction 208 consists of two messages: a write request 205 and a write response 206. The 
write request 205 consists of multiple network frames 201 through 204 and includes a header 
200 located in the beginning of the first network frame 201, which header specifies the various 
parameters of the request, such as file handle, offset, etc.; and the user data, often called payload, 
which is to be written to the file. In our example, the payload spans the multiple frames 201 
through 204." (paragraph [0132]). 

[001 1] It is a fact that FIG. 2 of Miloushev discloses, 
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[0012] It is a fact that Miloushev discloses, "FIG. 3 illustrates a way in which the file 
switch handles multi-frame transaction messages such as the write request 205. Upon receipt of 
the first frame 201, which contains the request header 200, the switch 100 recognizes that this 
frame signifies the beginning of a new message, examines the header 200 and decides to which 
of the file servers to forward the whole message. The file switch then replaces the header 200 
with the new header 300 containing modified request information as expected by the target file 
server and forwards the frame 201 with header 300 to the chosen file server." (paragraph [0137]). 

[0013] It is a fact that FIG. 3 of Miloushev discloses, 
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[0014] It is a fact that Miloushev discloses, "FIG. 4 illustrates the preferred way in which 
the file switch switches a complete file protocol transaction within the environment illustrated in 
FIG. 1. A client (not shown) is connected to the file switch 100, preferably through TCP, and in 
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fact views the file switch 100 as a file server. The client initiates a write transaction by issuing a 
request message 205 addressed to the file switch. Upon receipt of the first frame 201 of this 
message, the file switch has all information identifying the request, the file handle to which it 
pertains, and all other parameters of the request except for the payload." (paragraph [0141]). 
[0015] It is a fact that FIG. 4 of Miloushev discloses, 




[0016] It is a fact that Miloushev discloses, "Upon receipt of the complete request 205, 
the file server executes the action that the client connected through connection 109 originally 
requested from the file switch, forms a transaction response 206 containing response header 400, 
and sends the response back to the file switch 100 which the file server believes to be the 
originator of the request 205." (paragraph [0143]). 

[0017] It is a fact that Miloushev discloses, "The file switch receives the transaction 
response 206 and recognizes that it belongs to the same transaction as the previously switched 
request 205. The switch then examines the transaction reply header 400 and determines how to 
modify that header so that the client on connection 109 would accept the modified result as a 
valid response to the original request 205." (paragraph [0144]). 

[0018] It is a fact that Miloushev discloses, "Finally, the switch transmits the modified 
response 206 with the modified header 207 to the original client. The client receives the response 
and believes that the switch 100 has served the request 205 for it by executing the requested file 
system operation." (paragraph [0145]). 



Serial No. 10/767,593 



Page 13 of 20 



[0019] It is a fact that Miloushev discloses, "FIG. 6 illustrates rule-based namespace 
aggregation by the inventive file switch. The rules for namespace aggregation are preferably 
defined as a table of path correspondences. The first column specifies the names visible to the 
clients, the second column specifies the name of the server and, optionally a share or a mount 
point on that server, in which the files actually reside. File switch 100 is connected to three file 
servers 608, 609 and 610. Loaded within (or otherwise accessible by) the file switch is rule table 
604 that specifies three rules 605, 606 and 607. The path names 601, 602 and 603 of incoming 
file requests, such as file open, initiated by a network client are compared to the name-mapping 
rules in the first column (preferably the comparison is done longest matching prefix first, so that 
overlapping pathnames can be specified). If a match is found, the matching portion of the file 
base path is replaced with the name from the second column and the request is forwarded to the 
new path for processing. Once a file is open on the target server, all further transactions related 
to this file are switched to that server." (paragraph [0170]). 

[0020] It is a fact that FIG. 6 of Miloushev discloses, 
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2. The RFC 1094 Disclosure 

[0021] It is a fact that RFC 1094 discloses a Sun Network Filesystems (NFS) protocol 
that provides transparent remote access to shared files across networks. The NSF protocol is 
designed to be portable across different machines, operating systems, network architectures, and 
transport protocols. This portability is achieved through the use of Remote Procedure Call 
(RPC) primitives built on top of an external Data Representation (XDR). Implementations 
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already exist for a variety of machines, from personal computers to supercomputers. (1. 
Introduction). 

3. Argument 

[0022] The present invention discloses at least the features of: ... said client computer 
packetizes a request for storage from said client application as multiple standard Ethernet 
packets, each of said multiple Ethernet packets including a unique request identifier 
corresponding to said request for storage; said client computer combines said multiple Ethernet 
packets of said request for storage into one jumbo packet; . . . wherein said virtualizer: . . . 
translates said TCP/IP protocols of said request for storage received from said client computer 
into a network attached store protocol for communication with a plurality of network attached 
stores; ... wherein said single network attached store computer: processes, at one time, said 
request for storage according to said network attached store protocol", as recited in currently 
amended, independent claim 29, and "... packetizing, by said client computer, said request for 
storage as multiple standard Ethernet packets, each of said multiple standard Ethernet packets 
comprising said request for storage include a unique request identifier corresponding to said 
request for storage; combining, by said client computer, said multiple standard Ethernet packets 
of said request for storage into one jumbo packet; . . . translating, by said virtualizer, said TCP/IP 
protocols of said request for storage received from said client computer into a network attached 
store protocol for communication with one or more of a plurality of network attached stores; . . . 
processing at one time, by said single network attached store, said request for storage according 
to said network attached store protocol", as recited in currently amended, independent claim 30. 

[0023] In contrast, Miloushev merely discloses a computer network that decouples the 
client from the server, by placing a transparent network node, also termed a file switch or file 
switch computer, between the client and the server (Abstract), where the file switch preferably 
supports TCP and UDP IP network protocols and multiple industry standard network file 
protocols, such as NFS and CIFS." (paragraph [0123]). 

[0024] Applicants respectfully submit that nowhere does Miloushev disclose, teach or 
suggest at least the features of: "said client computer combines said multiple Ethernet packets of 
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said request for storage into one jumbo packet . . . translates said TCP/IP protocols of said request 
for storage received from said client computer into a network attached store protocol . . . wherein 
said single network attached store computer: processes, at one time , said request for storage 
according to said network attached store protocol", as recited in currently amended, independent 
claim 29, and "... packetizing, by said client computer, said request for storage as multiple 
standard Ethernet packets, each of said multiple standard Ethernet packets comprising said 
request for storage include a unique request identifier corresponding to said request for storage; 
combining, by said client computer, said multiple standard Ethernet packets of said request for 
storage into one jumbo packet; . . . translating, by said virtualizer, said TCP/IP protocols of said 
request for storage received from said client computer into a network attached store protocol for 
communication with one or more of a plurality of network attached stores; . . . processing at one 
time, by said single network attached store, said request for storage according to said network 
attached store protocol", as recited in currently amended, independent claim 30. That is, 
Miloushev does not disclose, teach or suggest combining multiple packets of a request for 
storage into a single jumbo packet and processing the request for storage at one time . Instead, 
Miloushev discloses processing of multiple packets (i.e., frames) serially (FIG. 4). 

[0025] RFC 1094 does not cure the deficiencies of Miloushev argued above. 

[0026] RFC 1094 merely discloses a Sun Network Filesy stems (NFS) protocol that 
provides transparent remote access to shared files across networks. (1. Introduction). 

[0027] Applicants respectfully submit that nowhere does RFC 1094 disclose, teach or 
suggest at least the features of: "said client computer combines said multiple Ethernet packets of 
said request for storage into one jumbo packet . . . translates said TCP/IP protocols of said request 
for storage received from said client computer into a network attached store protocol . . . wherein 
said single network attached store computer: processes, at one time , said request for storage 
according to said network attached store protocol", as recited in currently amended, independent 
claim 29, and "... packetizing, by said client computer, said request for storage as multiple 
standard Ethernet packets, each of said multiple standard Ethernet packets comprising said 
request for storage include a unique request identifier corresponding to said request for storage; 
combining, by said client computer, said multiple standard Ethernet packets of said request for 
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storage into one jumbo packet; . . . translating, by said virtualizer, said TCP/IP protocols of said 
request for storage received from said client computer into a network attached store protocol for 
communication with one or more of a plurality of network attached stores; . . . processing at one 
time, by said single network attached store, said request for storage according to said network 
attached store protocol", as recited in currently amended, independent claim 30. That is, RFC 
1094 does not disclose, teach or suggest combining multiple packets of a request for storage into 
a single jumbo packet and processing the request for storage at one time . Instead, RFC 1094 
merely discloses a Sun Network Filesystems (NFS) protocol that provides transparent remote 
access to shared files across networks. (1. Introduction). 

[0028] For at least the reasons outlined above, Applicants respectfully submit that 
Miloushev and RFC 1094, either individually or in combination, do not disclose, teach or 
suggest at least the present invention's features of: "said client computer combines said multiple 
Ethernet packets of said request for storage into one jumbo packet . . . translates said TCP/IP 
protocols of said request for storage received from said client computer into a network attached 
store protocol . . . wherein said single network attached store computer: processes, at one time , 
said request for storage according to said network attached store protocol", as recited in currently 
amended, independent claim 29, and "... packetizing, by said client computer, said request for 
storage as multiple standard Ethernet packets, each of said multiple standard Ethernet packets 
comprising said request for storage include a unique request identifier corresponding to said 
request for storage; combining, by said client computer, said multiple standard Ethernet packets 
of said request for storage into one jumbo packet; . . . translating, by said virtualizer, said TCP/IP 
protocols of said request for storage received from said client computer into a network attached 
store protocol for communication with one or more of a plurality of network attached stores; . . . 
processing at one time, by said single network attached store, said request for storage according 
to said network attached store protocol", as recited in currently amended, independent claim 30. 
Accordingly, Miloushev and RFC 1094, either individually or in combination, fail to render 
obvious the subject matter of currently amended, independent claims 29 and 30, and dependent 
claims 2, 5-7, 10, 11, and 20 under 35 U.S.C. §103(a). The rejection of canceled claims 18 and 
19 is moot. Withdrawal of the rejection of claims 2, 5-7, 10-11, 18-20, and 29-30 under 35 
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U.S.C. § 103(a) as unpatentable over Miloushev and RFC 1094 is respectfully solicited. 

B. The 35 U.S.C. 103(a) Rejection over Miloushev, RFC 1094, and RFC 791 

1. The RFC 791 Disclosure 

[0029] It is a fact that RFC 791 discloses, "The Internet Protocol is designed for use in 
interconnected systems of packet-switched computer communication networks. Such a system 
has been called a "catenet" [1]. The internet protocol provides for transmitting blocks of data 
called datagrams from sources to destinations, where sources and destinations are hosts 
identified by fixed length addresses. The internet protocol also provides for fragmentation and 
reassembly of long datagrams, if necessary, for transmission through "small packet" networks." 
(DARPA Internet Program Protocol Specification, 1. Introduction, 1.1 Motivation). 

2. Argument 

[0030] The present invention discloses at least the features of: "... packetizing, by said 
client computer, said request for storage as multiple standard Ethernet packets, each of said 
multiple standard Ethernet packets comprising said request for storage include a unique request 
identifier corresponding to said request for storage; combining, by said client computer, said 
multiple standard Ethernet packets of said request for storage into one jumbo packet; . . . 
translating, by said virtualizer, said TCP/IP protocols of said request for storage received from 
said client computer into a network attached store protocol for communication with one or more 
of a plurality of network attached stores; . . . processing at one time, by said single network 
attached store, said request for storage according to said network attached store protocol", as 
recited in currently amended, independent claim 30. 

[0031] In contrast, RFC 791 merely discloses that the internet protocol provides for 
transmitting blocks of data called datagrams from sources to destinations, where sources and 
destinations are hosts identified by fixed length addresses and for fragmentation and reassembly 
of long datagrams ... ." (DARPA Internet Program Protocol Specification, 1. Introduction, 1.1 
Motivation). 
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[0032] Applicants respectfully submit that nowhere does RFC 791 disclose, teach or 
suggest at least the features of: "... packetizing, by said client computer, said request for storage 
as multiple standard Ethernet packets, each of said multiple standard Ethernet packets 
comprising said request for storage include a unique request identifier corresponding to said 
request for storage; combining, by said client computer, said multiple standard Ethernet packets 
of said request for storage into one jumbo packet; . . . translating, by said virtualizer, said TCP/IP 
protocols of said request for storage received from said client computer into a network attached 
store protocol for communication with one or more of a plurality of network attached stores; . . . 
processing at one time, by said single network attached store, said request for storage according 
to said network attached store protocol", as recited in currently amended, independent claim 30. 
That is, RFC 791 does not disclose, teach or suggest combining multiple packets of a request for 
storage into a single jumbo packet and processing the request for storage at one time . Instead, 
RFC 791 merely discloses that the internet protocol provides for transmitting blocks of data 
called datagrams from sources to destinations, where sources and destinations are hosts 
identified by fixed length addresses and for fragmentation and reassembly of long datagrams . . . 
." (DARPA Internet Program Protocol Specification, 1. Introduction, 1.1 Motivation). 

[0033] For at least the reasons outlined above with respect to the rejection of the claims 
over Miloushev and RFC 1094, and for at least the reasons outlined immediately above with 
respect to the rejection of the claims over RFC 791, Applicants respectfully submit that 
Milosushev, RFC 1094, and RFC 791, either individually or in combination, do not disclose, 
teach of suggest at least the present invention's features of: "". . . packetizing, by said client 
computer, said request for storage as multiple standard Ethernet packets, each of said multiple 
standard Ethernet packets comprising said request for storage include a unique request identifier 
corresponding to said request for storage; combining, by said client computer, said multiple 
standard Ethernet packets of said request for storage into one jumbo packet; . . . translating, by 
said virtualizer, said TCP/IP protocols of said request for storage received from said client 
computer into a network attached store protocol for communication with one or more of a 
plurality of network attached stores; . . . processing at one time, by said single network attached 
store, said request for storage according to said network attached store protocol", as recited in 
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currently amended, independent claim 30. Accordingly, Milosushev, RFC 1094, and RFC 791, 
either individually or in combination, fail to render obvious the subject matter of currently 
amended, independent claim 30 and dependent claim 22 under 35 U.S.C. § 103(a). Withdrawal 
of the rejection of claim 22 under 35 U.S.C. § 103(a) as unpatentable over Milosushev, RFC 
1094, and RFC 791 is respectfully solicited. 

III. Formal Matters and Conclusion 

Claims 2, 5-7, 10, 11, 20, 22, and 29-32 are pending in the application. 

With respect to the rejections of the claims over the cited prior art, Applicants 
respectfully argue that the present claims are distinguishable over the prior art of record. In view 
of the foregoing, the Examiner is respectfully requested to reconsider and withdraw the 
rejections to the claims. 

In view of the foregoing, Applicants submit that claims 2, 5-7, 10, 1 1, 20, 22, and 29-32, 
all the claims presently pending in the application, are patentably distinct from the prior art of 
records and are in condition for allowance. The Examiner is respectfully requested to pass the 
above application to issue at the earliest time possible. 

Should the Examiner find the application to be other than in condition for allowance, the 
Examiner is requested to contact the undersigned at the local telephone number listed below to 
discuss any other changes deemed necessary. 

Please charge any deficiencies and credit any overpayments to Attorney's Deposit 
Account Number 09-0441. 

Respectfully submitted, 



Dated: August 31, 2009 /Peter A. Balnave/ 

Gibb LP. Law Firm, LLC Peter A. Balnave, Ph.D. 

2568-A Riva Road, Suite 304 Registration No. 46,199 

Annapolis, MD 21401 

Voice: (410) 573-5255 

Fax: (301) 261-8825 

Email: Balnave® gibbiplaw.com 

Customer Number: 29154 
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